---title: "Transcrição da Prova Teórica 1 — nome: " disciplina: "Gestão de Projetos de Software" codigo_disciplina: "GPS" avaliacao: "Prova Teórica 1" periodo: "2026-2" data: "2026-10-19" discente: nome: "Nathan Balmant De Paula Assunção" matricula: "20223004358" curso: "Engenharia de Computação" turma: "Unidade Timóteo" nota_total: 21.6 nota_maxima: 25.0 legibilidade_percentual: 93 metadados_transcricao: transcritor: "Antigravity Assistant (Visão Computacional)" data_transcricao: "2026-10-19" grau_fidelidade: "Fiel (ipsis litteris), preservando pontuação e caligrafia original" format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Transcrição da Prova Teórica 1 — Nathan Balmant De Paula Assunção ## Questão 1 ### 1.1 (1,5) Projeto vs. operação — três características com evidências: O Professor Agente é um projeto devido a sua idealização de ter início, meio e fim, junto com a evidência de que conseguimos perceber que o Professor Agente não é uma tarefa rotineira como uma manutenção por exemplo, por ultimo pelo contexto podemos ver que o Professor Agente foi reparado por sprints com diferentes tarefas, característica de um projeto. ### 1.2 (2,0) Duas alternativas de trade-off sem sacrificar qualidade + impacto no Triângulo de Ferro: Segundo o Triângulo de Ferro se o escopo precisa ser modificado, para não comprometer a qualidade deve-se então ajustar o tempo e/ou custo. Poderíamos então contratar um especialista para resolver/orientar no problema de integração (aumentando custo) ou aumentar o tempo estudando estratégias de integração com LLMs. ### 1.3 (1,5) Ciclo de vida e justificativa (preditiva, ágil ou híbrida): O ciclo de vida é de tamanho de semestre (15 semanas) cerca de 7,5 sprints e sua abordagem é ágil devido a sua característica de dividir tarefas (escopo) por sprints de forma maleável fixando o tempo (duração). --- ## Questão 2 ### 2.1 (1,5) EAP de dois níveis (substantivos, regra dos 100%, $\ge 3$ pacotes de trabalho): ``` [Espaço para desenho/diagrama da EAP] /--- Project Charter Documentação ----+---- EAP \--- Readme /--- Integração LLM Implementação ----+---- Armazenamento de conversas \--- Interface de chat ``` Os pacotes de trabalho podem ser Project Charter, Readme e Integração com LLM. A EAP tem seu diagrama montado por níveis de hierarquia até chegar em pacotes de trabalho detalhando quais tarefas cada entrega precisa para finalizar. ### 2.2 (1,5) Issue completa (título, descrição, critério, estimativa/estratégia) e 2ª Issue com justificativa relativa: Issue 1: Título: Realizar Integração LLM ; Descrição: Fazer rotação de chaves e validação no backend ; Critério: Tempo de resposta menor que 1 seg ; Estimativa: 10 horas Issue 2: Título: Realizar Readme ; Estimativa: 2 horas A complexidade das duas issues são bem diferentes por isso a primeira issue tem uma estimativa maior. ### 2.3 (2,0) Milestones vs. Sprints + contexto para Kanban sem Sprints: Milestones não substituem em vários casos, principalmente ao usar plataforma de gestão onde tarefas vão estar ligadas a sprints, e as sprints que vão ajudar no controle de esforço dos cards em andamento. Kanban sem sprints pode ser adequado em projetos simples e de curta duração onde o escopo é fixo. --- ## Questão 3 ### 3.1 (1,5) DoD, relação com pipeline CI/CD e omissão de testes de segurança: Com os testes omitidos não encontraremos problemas no projeto, e levaríamos um produto incompleto para produção, o pipeline CI/CD nos ajuda a controlar isso porque cada mudança de código só é aceita caso passe nos testes e funcione. ### 3.2 (1,5) CoQ — classificar (a), (b), (c), (d) + custo mais alto: a) Avaliação b) Prevenção c) Falha interna d) Prevenção O mais alto é o C, pois essa falha em produção acarreta em muito mais dificuldade de correção e impactos grandes. ### 3.3 (2,0) Heurística 1:10:100, limites em IA e uso como argumento qualitativo: Essa heurística consiste em 1 é o custo para corrigir um problema na fase inicial do projeto, 10 é o custo se o problema for resolvido em uma fase intermediária de validações e 100 é o custo para resolver um problema em produção. Ela deve ser usada como uma metodologia de ensino para justificar porque gastar mais tempo com um bom planejamento e execução na fase inicial do que levar problemas graves para produção. --- ## Questão 4 ### 4.1 (1,5) Risco vs. problema (Cap. 6) + quadrante na matriz $P \times I$ e estratégia de resposta: ``` Prob. ^ | Médio Crítico | Vazamento chave API | | Baixo Médio +-------------------------> Impacto ``` Ele poderia ser um risco mas virou problema depois que o vazamento aconteceu, pois risco são eventos que podem acontecer algum dia. Esse risco foi classificado como probabilidade média e impacto crítico, pois sem cuidado (.env, gitignore) ele pode acontecer, e o vazamento pode gerar custos grandes. ### 4.2 (1,5) Três ações imediatas + uma ação preventiva (defesa em profundidade): Ações imediatas seriam rotacionar a chave, privar o projeto e validar histórico de commits. Sobre ações planejadas, deveríamos ter processos automatizados antes do commit e PR que validam chaves expostas e manter ou criar um arquivo .env e .gitignore. ### 4.3 (2,0) Risco de entrada modelado (causa, P, I, mitigação, contingência) + mitigação de saída + artefato de documentação: Risco de Prompt Injection, por causa de não validação no backend, probabilidade média, impacto alto, mitigação seria validar esse tipo de invasão deterministicamente no backend. Risco de saída são respostas erradas (alucinações) que devem ser mitigadas controlando janela de contexto e quantidade de tokens. Para registrar pode ser um ADR. --- ## Questão 5 ### 5.1 (1,5) Comunicação síncrona vs. assíncrona no GitLab + prática/ritual de registro de decisões: A comunicação síncrona é rápida e objetiva enquanto a assíncrona gera histórico de decisões. Uma prática interessante é sempre após decisões criar um ADR através de Issues e manter esse histórico com rastreabilidade para o time, assim mesmo em comunicação síncrona as decisões vão estar registradas. ### 5.2 (1,5) Matriz Poder $\times$ Interesse dos 5 stakeholders, premissas e estratégia de comunicação: ``` Poder ^ | Manter satisfeito Gerenciar de perto | 2, 3 | | Monitorar Manter informado | 4, 5 1 +---------------------------------------------> Interesse Legenda: 1. Alunos que usam o chat 2. Professor 3. Equipe Desenvolvendo 4. Provedor da API 5. Coordenação Curso ``` Professor é Gerenciar de Perto por ter bastante poder ao ser o avaliador do projeto e ter bastante interesse pelo projeto ser na sua disciplina. Alunos que vão usar é Manter informado por terem bastante interesse contudo baixo poder no projeto. O canal para comunicar com professor é na sala de aula, 1x por semana e em decisões importantes e dúvidas. ### 5.3 (2,0) Conflito pedagógico vs. técnico — Thomas-Kilmann (1 escolha justificada + 2 inadequadas): Deveríamos conter esse conflito ao explicar para o cliente que é melhor respostas menores e certas do que detalhadas mas erradas. Como ações inadequadas não deveríamos ignorar o pedido do cliente, e nem atender de forma completa, pois isso iria alterar e piorar o funcionamento do chat.